IBIS Macromodel Task Group

Meeting date: 08 October 2024

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Altair:                     * Junesang Lee
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Aurora System:              * Dian Yang
                              Raj Raghuram
Cadence Design Systems:     * Ambrish Varma
                            * Jared James
Dassault Systemes:            Longfei Bai
Google:                       Hanfeng Wang
                              GaWon Kim
Intel:                      * Michael Mirmak
                              [Kinger Cai]
                            * Chi-te Chen
                              Liwei Zhao
                              Alaeddin Aydiner
                              Sai Zhou
Keysight Technologies:        Fangyi Rao
                              Majid Ahadi Dolatsara
                              Stephen Slater
                              Ming Yan
                              Rui Yang
Marvell:                      Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Graham Kus
Micron Technology:            Justin Butterfield
Missouri S&T:                 Chulsoon Hwang
                            * Yifan Ding
                              Zhiping Yang
Rivos:                        Yansheng Wang
SAE ITC:                      Michael McNair
Samsung:                      Jun-Bae Kim
Siemens EDA (Mentor):       * Arpad Muranyi
                            * Randy Wolff
Signal Edge Solutions         Benjamin Dannan
Teraspeed Labs:               [Bob Ross]
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

Yifan:  Draft a new version of BIRD220.1 including language describing the
        limitations of the approach.
        - Done.  Yifan said she had an update to present.

Michael:  Check to see if see if Ts4file cross checking code could be donated
          for use by the ibischk parser.
          - Done.  Michael reported that he had checked the GitHub project he
            had in mind, but he found that the code was distributed under GPL.
            He said this licensing scheme would make it difficult to incorporate
            the code into ibischk or tschk.  We would have to make a special
            inquiry to the authors.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the October 1st
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

--------------
New Discussion:

BIRD220.1 update:
Yifan noted that she had sent out a new draft of BIRD220.1 that contained 
language describing the limitations of the approach.  She said she was awaiting
feedback.

Arpad said he had reviewed the draft, and he expressed concern about this
sentence:
  If the pre-drivers have similar on-times, it is recommended to use an
  equivalent PSIJ for the combined pre-driver stages.
Arpad said he thought the results of Yifan's previous investigations had
confirmed that the algorithm could not be applied to devices with independent
pre-driver stages, even if their delays were similar.  Yifan referred to a
subsequent sentence noting that the pre-driver PSIJ must be measured under the
"same load conditions expected in the application" in order to ensure accuracy.
Arpad asked whether a difference in "load conditions" referred only to the load
itself or also the V_fixture into which it was driven.  Yifan said PSIJ depended
upon the load and V_fixture, in the case of independent pre-driver stages.

For illustrative purposes, Arpad proposed an example with a capacitive load.  He
said that at the start of a rising edge, the buffer is in the low state and the
capacitor is discharged.  As the buffer starts to drive the rising edge, the
discharged capacitor effectively looks as though the load is V_fixture = 0V.
Once the device is at steady state high, and the capacitor has charged up, the
load will look like V_fixture = Vcc when the falling transition begins.  So, his
fear was that the effective "load conditions" would change.  Yifan said she
would perform more case studies and investigate.

Arpad also requested that the BIRD further explain "DC Jitter Sensitivity" and
contrast it with "AC noise".  Yifan said that the DC Jitter Sensitivity
algorithm can be extended to handle AC power noise by integrating the power rail
voltage over time.  Arpad asked that the explanations be added in one of the
keyword sections, for example Usage Rules, instead of the Definition of the
Issue section of the BIRD, which does not become part of the specification.

Ts4file and [Ramp]:
The group continued the previous discussions, and Michael focused on the table
Walter had created enumerating the combinations of I-V, V-t, Ts4file, and
External Model and their interactions with [Ramp].  Michael noted that Walter
had updated the table during/after the previous meeting.

Michael summarized the discussions regarding the parser cross checking [Ramp]
information.  He said we all agree the cross checking anything against [External
Model] is beyond the scope of the parser.  However, should we implement the
missing checks of [Ramp] against other data (Ts4file, V-t waveforms)?  Michael
noted that Arpad had proposed adding additional loading information variations
to the [Ramp] keyword, so it could be cross checked against the V-t waveforms.

Arpad noted that he and Walter had preferred to keep [Ramp] as a required
keyword.  Ambrish said he did not.  He said IBIS had always progressed with the
idea that a new keyword might not be supported yet by a particular tool, so we
keep a valid [Ramp] around for tools that don't support the newer keywords.  He
said that was originally done when V-t waveforms were added, and the same thing
was done when [External Model] was added.  He said we could do the same thing
for Ts4file, knowing full well that [Ramp] information isn't needed in a Ts4file
simulation.  Walter said we ignore [Ramp] for the purposes of the actual
simulation in a Ts4file case, but [Ramp] is still useful to EDA tools for other
purposes.

Arpad said Ts4file is itself a special case.  While [External Model] is clearly
intended to replace the contents of the legacy analog keywords, the Ts4file
section says Ts4file is "intended exclusively for AMI applications."  If that is
the case, then the [Model] must be able to provide other information for non-AMI
simulations.  Since the Ts4file section recommends [External Model] for the
purposes of non-AMI simulation, and [External Model] replaces the legacy
keywords, we might then arrive at the conclusion that legacy keywords should be
ignored in Ts4file models.  But it takes two steps to arrive at that conclusion
and isn't explicitly stated.  In addition, Arpad said one limitation of Ts4file
4-port data models is that they aren't useful for power integrity simulations.
Therefore, it's not enough to just wrap a Ts4file in an [External Model] and say
it's sufficient for non-AMI purposes.

Ambrish said all of those arguments were valid back when Ts4file was introduced
and added to the .ami file.  He said we casually put this aspect of the channel
characterization in the .ami file, and we knew then that there would be many
simulations that needed nothing from the .ibs file.  We should have put this
Ts4file information in the .ibs file back then.  Arpad agreed, but he said we've
gained some new insights in the ten years since that was done.

Michael said the question remains, should we remove the requirement for [Ramp],
or should we consider adding new cross checks if we keep it?  Ambrish said he
felt it should not be required.  Walter and Arpad preferred to keep [Ramp] as
a required keyword.  Walter said even when [Ramp] data isn't used in the actual
simulation, it provides useful information to the simulator for time stepping.
Curtis said he preferred to keep the [Ramp] requirement, but he said Ambrish's
recollection was historically accurate.  He said Ambrish had originally
expressed concern about putting the Ts4file in the .ami file as a parameter.  He
agreed with Ambrish that some of these new complications arise from the fact
that we're now contemplating [Model]s that violate the original spirit of
"intended exclusively for AMI applications" and the recommendation that [External
Model] be used to provide comparable information for non-AMI simulations.

Walter said he was okay with adding additional cross checks, but he asked why
we would do it.  He said the different keywords represent two different
behaviors.  If you have I-V curves and C_comp, you can't handle reflections.
That's why Ts4file was important.  Models are for making engineering decisions.
Sometimes Ts4file is the best choice for making a decision, sometimes it's not.
Arpad said that's true, but the checking is also for the model maker.  We want
to alert the model maker to any discrepancies with a warning, not an error.  You
wouldn't want a model that gave 2x or 3x the amplitude or edge rate depending on
which keyword you used.

Michael said he thought he had some direction for his next draft BIRD update.
He said he would not change the [Ramp] requirement, but he would add some new
text clarifying the cross checks.  He said he might revisit the [External
Model] text as well.

- Michael: Motion to adjourn.
- Ambrish: Second.
- Arpad: Thank you all for joining.

New ARs:

Yifan:  Perform additional investigations into the applicability of BIRD220.1
        for devices with independent pre-driver stages.

Michael:  Prepare a new draft BIRD updating the language surrounding Ts4file and
          Ramp and related cross checking.

-------------
Next meeting: 15 October 2024 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
